home *** CD-ROM | disk | FTP | other *** search
- Date: Tue, 12 Jul 94 23:57 CDT
- From: ekl@sdf.lonestar.org (Evan K. Langlois)
- To: gem-list@world.std.com
- Subject: Buttons Buttons Buttons
- Precedence: bulk
-
-
- There has been some discussion on buttons, so here is my recommendation.
-
- For the sake of simplicity in this suggestion, I will number the buttons
- since left and right are ambiguous. Numbering is as follows.
-
- Two Button Mice Three Button Mice Four Buttons
- 1 2 1 3 2 1 3 4 2
-
- All Applications should use the leftmost (primary) button, #1 for selection
- of objects on the desktop and the top window, and in any menus. The use
- of other buttons is as follows :
-
- Tool-based Applications : All other buttons are used to select tools. So,
- you assign a tool to a mouse button by clicking on it with that button. You
- can then have 2 active tools on a standard ST mouse and you could even use
- them at once (press both buttons). Other mice will allow you to have
- multiple tools assigned, one per button. To reassign, just select a tool
- with that button. Tool bars are never toppable, so a left click will
- be a "click" and not a "top", and when the AES sends a "top" message, just
- pretend its a click message.
-
- Other Applications : The secondary mouse button is to be used to pop-up a
- menu based on the location or window or dialog or icon that you click on.
- The second button pops up a menu identicle to the GEM menu bar, except for
- being vertical instead of hierarchal, when you click on empty desktop, and
- the GEM sub-menus are attached to this. In a "background" window, the buttons
- are "shifted" down one, so that the first button only tops windows, and
- the second button is used to select items in a background window. If that
- window has a special pop-menu then you either have to top the window to
- use it, or use the THIRD mouse button.
-
- Other than that mentioned above, 3rd and 4th mouse buttons can pull up
- special menus (that would otherwise be nested in the application's menu)
- when these buttons have no other uses (such as any use of 4th mouse buttons
- or use of a third mouse button on a foreground window or bare desktop).
- These may include font selectors, an info panel, etc.
-
- In any case, if you wish to implement a permanent menu that stays on
- screen (in a window) after being pop-ed up, then only make the menu
- stay on-screen when the unused. For example, user presses right button
- and gets pop-up, and holds right button , going through sub-menus and
- finds a menu he wants to use. His choice is to select a menu item,
- making the menu go away, or he can drag the mouse off the menu which
- turns it from a modal menu, into a window with a menu inside that can
- moved around, closed, or used. When used as a window, it stays onscreen
- until closed. Also, this should only be done for right-button menus.
- Menus called from a 3rd or 4th button (even if called from a background
- window) should never stay in a window, and pop-up info should only stay
- until you release the mouse button) although these menus should be
- available in the main menu tree.
-
- Am I making any sense here? Probably not. Anyway, this isn't standard's
- proposal, its just a couple suggestions on what to do with extra buttons.
-
- Oh .. I forgot to mention this. NEVER force the user to hold both
- buttons to produce any effect. The only reason to hold two buttons is
- to do two things at once (maybe use your brush1 and blur tools at once).
- If you can't figure out how to wait for EITHER button, ask someone and
- they will explain. Do NOT hack things by using the right button to
- modify the event you get with the left button. You CAN get separate
- left and right button events (although its a bit weird).
-
-